WNS-28 Fix WIRE-349 creator chain-kind validation - #601

Reviewed against the CertiK WNS-28 report. The fix is correct and complete for the reported issue.

What I checked beyond the diff itself:

The premise holds. sysio.msgch::dispatch_reserve_create binds ext.chain_code to the proven delivering outpost, then forwards rc.creator_addr.kind verbatim — so chain_code is proven and the creator kind is free-form payload, exactly as reported.

The invariant cannot drift. regchain is the only writer of a chain row's kind; activchain and setoutpost do not touch it, and there is no erase. A registered code's kind is therefore immutable, which is what makes resolving it independently in oncrtreserve and matchreserve sufficient rather than needing the kind pinned on the reserve row.

Consistent with existing precedent. sysio.uwrit::swapfromwire already enforces the same registry-kind equality for recipient_kind, so this brings oncrtreserve in line rather than introducing a new pattern.

The committed WASM carries the fix. Since CI deploys the checked-in artifact as-is, I checked the binary rather than the source: the new rejection string is present in the committed wasm and absent from the base. The ABI is untouched, consistent with the unchanged action signature.

The regression test is genuine. authex::recordlink does not validate key type against chain_kind, and bypubkey is keyed on the key hash with no kind component — so pre-fix the SVM-linked ED key would have resolved as linked and produced a PENDING row. The test fails without the change.

Reclaim interaction is sound. A mismatched create against a live PENDING row hits the existing-row guard; against a CANCELLED row it takes the no-double-refund branch. Neither clobbers a legitimate reserve.

One design question, not a blocker: the mismatch adds a new trigger for writing a CANCELLED tombstone and queueing a refund on a triple that a legitimate creator can later reclaim. The comments here assume the outpost refunds idempotently per (chain, token, reserve_code). If a tombstone refund can land after a reclaiming creator's escrow is already locked, that is a cross-chain desync — pre-existing on the unlinked-creator path, but this widens the trigger set. Worth confirming against the outpost side.

Three minor notes inline, none blocking.

Separately, I filed SEC-158 for the same unvalidated-payload-kind pattern in sysio.dclaim::onreward, where it is reachable through the staking-reward path and the consequence is a replay-cursor bypass rather than a stuck row. Out of scope for this PR.

Re-review of the current head (e7c911caa9). All three of my earlier comments are genuinely addressed — I verified each against the outposts rather than the replies alone.

Comment 1 (address vs. kind) — creator_address_matches_kind is correct against both live emitters: ETH ReserveManagerLib.sol:271 sends abi.encodePacked(sender) (20 bytes) with CHAIN_KIND_EVM; SOL reserve.rs:241 and init_liqsol_reserve.rs:307 send creator.to_bytes() (32 bytes) with ChainKindSvm. No regression for either.

Comment 2 (oncnclrsv) — resolved-kind comparison is in. One note below: it is not the no-op I implied when I called it cosmetic.

Comment 3 (refund unproven) — deploy_msgch() + the attestation-row assertion make it a real regression test; pre-fix the row is PENDING, so the status assertion already fails.

Threat model

Since the outposts are ours and honest, WNS-28 is not reachable through the normal create path at all — both outposts hardcode creator_addr.kind and the address shape, so a disagreeing payload would require forging at the OPP layer. That makes these guards defense-in-depth, which is the right call and consistent with the sysio.uwrit::swapfromwire precedent. It also reorders what actually matters below: the honest-outpost failure mode (a future chain kind) is the practically relevant one, not the adversarial one.

Artifact

Verified rather than assumed, since linux_amd64_build.yaml:267 sets SYSIO_BUILD_SYSTEM_CONTRACTS: OFF on non-tag refs — CI stages and tests the committed WASM. CI is green on e7c911caa9 across all five variants, so the committed artifact provably passes both new regression tests.

One stale item: the PR body's 1c6dd55b… is the b4f22e8415 artifact, superseded by the master merge (which changed reserv.cpp: WIRE_SYMBOL → opp::wire::asset_symbol). The head artifact is 7381b0f44d135b192b68c2ba79e77cd0962c201dc8f0d15bc98ec56a9a5fd325, and the "CI evidence pending" note is now out of date. Worth refreshing the body.

Separate issue, not this PR — the reclaim carve-out is unreachable

This closes the design question I left open. oncrtreserve's reclaimable_cancelled branch exists so a CANCELLED row does not permanently burn a (chain, token, reserve_code) identity. Neither outpost has a counterpart:

• ETH — onReserveCreateCancelled sets status = CANCELLED and leaves rec.exists = true; _recordAndEmitReserveCreate reverts WIRE_ReserveAlreadyExists whenever exists.
• SOL — create_reserve uses Anchor init on the Reserve PDA; handle_reserve_create_cancelled flips status and refunds but never closes it, and the only closer (admin_close_pending_reserve_handler) requires status == Pending.

This does not depend on outpost honesty: all three ETH entries are external whenNotPaused OPPEnabled with no role gate, and SOL's own comment says create_reserve is permissionless. So any user can burn a reserve code permanently — create with an unlinked creator key, take the refund, leave the slot dead. The SOL admin escape hatch was built for the Pending griefing case and does not cover the post-cancel state.

Pre-existing, and this PR does not widen it in practice — the two new triggers cannot be produced by the honest outposts. Flagging it because this PR's comments (and my earlier review) both lean on reclaimability being real. Happy to file it separately.

Verdict

The fix is correct and complete for WNS-28, and the committed artifact carries it. The two inline notes are coverage gaps in the exact predicates this PR changed; neither is a correctness blocker.